Object persister

ABSTRACT

Here is described an implementation of an object persister, which serializes an object to preserve the object&#39;s data structure and its current data. The serialized object is encoded using XML and inserted within a message. That message is transmitted to an entity over a network. Such a transmission is performed using standard Internet protocols, such as HTML. Upon receiving the serialed object, the receiving entity deserializes the object to use it. Rather than include copies of referenced objects within the serialized object, the object persister includes references to those objects. This avoids redundant inclusion of the same object and potentially infinite inclusion of the object itself that is being serialized.

RELATED APPLICATIONS

[0001] This application is a continuation of and claims priority to U.S.patent application Ser. No. 09/635,830, filed Aug. 9, 2000, thedisclosure of which is incorporated by reference herein.

TECHNICAL FIELD

[0002] This invention relates the preservation of objects for laterrecovery and use.

BACKGROUND

[0003] Storing an object for later use by an application is called“object persistence.” In addition, encoding an object for transmissionover a distributed network is called object persistence. Objectpersistence is also known as “serializing an object.” An “object” is thecore concept of an “object-oriented paradigm.

[0004] Object-Oriented Paradigm

[0005] A large segment of the computing realm operates under theobject-oriented paradigm. This is sometime called “object technology” or“object-oriented programming.” In general, an object is understood toencapsulate data and procedures (i.e., methods).

[0006] Object-oriented programming is a type of programming in whichprogrammers define not only the data type of a data structure, but alsothe types of operations (i.e., procedures, functions, or methods) thatcan be applied to the data structure. In this way, the data structurebecomes an object that includes both data and functions. In addition,programmers can create relationships between one object and another. Forexample, objects can inherit characteristics from other objects.

[0007] One of the principal advantages of object-oriented programmingtechniques over procedural programming techniques is that they enableprogrammers to create modules that do not need to be changed when a newtype of object is added. A programmer can simply create a new objectthat inherits many of its features from existing objects. This makesobject-oriented programs easier to modify.

[0008] To perform object-oriented programming, one needs anobject-oriented programming language (OOPL). “Java,” “C++,” and“Smalltalk” are three of the more popular languages, and there areobject-oriented versions of Pascal.

[0009] The object-oriented paradigm allows for the fast development ofapplications to solve real problems. Using this paradigm, applicationscan interact with other applications (or the operating system) on thesame computer. Such an interaction may involve sharing data orrequesting execution of a task by another application. For example, theComponent Object Model (COM), by the Microsoft Corporation, enablesprogrammers to develop objects that can be accessed by any COM-compliantapplication on the same computer.

[0010] The object-oriented paradigm also allows applications to interactwith applications on different computers. This is often called“distributed computing.”

[0011] Generally, distributed computing utilizes different componentsand objects comprising an application that are located on differentcomputers coupled to a network. So, for example, a word processingapplication might consist of an editor component on one computer, aspell-checker object on a second computer, and a thesaurus on a thirdcomputer. In some distributed computing systems, each of the threecomputers could even be running a different operating system.

[0012] One of the requirements of distributed computing is a set ofstandards that specify how objects communicate with one another. Thereare currently two chief distributed computing standards: CORBA (CommonObject Request Broker Architecture) and DCOM (Distributed ComponentObject Model).

[0013] For example, programmers may use DCOM (by the MicrosoftCorporation) to develop objects that can be accessed by anyDCOM-compliant application on a different computer. DCOM is an extensionof COM to support objects distributed across a network.

[0014] Object Serialization

[0015] Serialization is the process of saving and restoring objects.More precisely, serialization is the process of saving and restoring thecurrent data and the data structures of objects. The information isextracted from objects so that it is not lost or destroyed. In otherwords, the transitory status of objects is fixed (often in a file or adatabase) for the purpose of storage or communications. This process isalso called “object persistence.”

[0016] If an application using an object is closed, then the object'sdata and its data structures must be preserved so that the object may berestored into its current state when the program is invoked again. Forexample, it is often necessary to temporarily store an object so thatanother application may access it. In another example, sending an objectto another computer in a distributed computing environment requires theobject be stored, transmitted, received, and recovered. In each of theseexamples, objects are stored and restored.

[0017] When serializing an object, the focus is not so much on how tostore an object's data in non-volatile memory (such as a hard drive),but rather on how the in-memory data structure of an object differs fromhow the data appears once it has been extracted from the object. Inmemory, the data is located at arbitrary addresses, which areconceptually defined as data structures including data, arrays, objects,methods, and the like. However, these data structures cannot be storeddirectly.

[0018] To store a data structure, it must be broken down into itscomponent parts, which includes simple data types like integers,strings, floating point numbers, etc. In addition, the hierarchicalarrangement within each data structure must be stored and maintained.Furthermore, the hierarchical arrangement of data structures themselvesmust be stored and maintained.

[0019] The serialized data of an object may be thought of as a“dehydrated object” where all of the water (object functions in thismetaphor) has been squeezed out of the object. This leaves only drypotato flakes (the data). Later, a hungry person wishes to have mashedpotatoes (the object with the data), the potato flakes may berehydrated. To “add water” to a dehydrated object, an empty object iscreated and the stored data is inserted therein.

[0020] Serialization of an object is an effective and important step inexchanging the object between computers. These types of object exchangesare important to a distributed computing environment where computersactively distribute objects across a network. Those of ordinary skill inthe art are familiar with object serialization.

[0021] Serialization Issues

[0022] Separating Data Items: When serializing an object, data itemsmust be separated from each other when they are stored. Otherwise, theywill not be properly identified later when reading the data back into anew object during deserialization. Therefore, a serialization schememust specify how data items are separated from each other.

[0023] Preserving Hierarchical Structure: Unless the hierarchicalstructure of the data is preserved during the serialization process, itcannot be recreated during a deserialization. Each data structure ispotentially different from each other.

[0024] Therefore, a serialization scheme must have a general data formatsuiting the needs of all potential data structures of an object.Typically, such a scheme accomplishes this by having the capability todelimit arbitrary nested data, that is, truly hierarchical datastructures.

[0025] Preserving Object Relationships: Often objects include referencesto other objects. When in memory, this reference is often a pointer inmemory to the other objects. When serializing an object with a referenceto another object, the serialized object includes the entire object likeits does for a data structure.

[0026] However, if there are multiple references to the same object,then there are redundant inclusions of the same object. Furthermore, ifthe reference within an object is to itself (directly or indirectly),then the serialization process may fail because it is circularly andpotentially infinitely storing object data.

[0027] Extensible Markup Language (XML)

[0028] SGML (Standard Generalized Markup Language) is a generic textformatting language that is widely used for large databases and multiplemedia projects. It is particularly well suited for works involvingintensive cross-referencing and indexing.

[0029] HTML (HyperText Markup Language) is a specific implementation ofa subset of SGML and is nearly universally used throughout the global asthe foundation for the World Wide Web (“Web). HTML uses tags to markelements, such as text and graphics, in a document to indicate how Webbrowsers should display these elements to the user. HTML tags alsoindicate how the Web browsers should respond to user actions such asactivation of a link by means of a key press or mouse click.

[0030] XML (eXtensible Markup Language) is a specific implementation ofa condensed form of SGML. XML lets Web developers and designers createcustomized tags that offer greater flexibility in organizing andpresenting information than is possible with the HTML document codingsystem.

[0031] In HTML, both the tag semantics and the tag set are fixed. XMLspecifies neither semantics nor a tag set. In fact, XML is really ameta-language for describing markup languages. In other words, XMLprovides a facility to define tags and the structural relationshipsbetween them. Since there's no predefined tag set, there are nopreconceived semantics. All of the semantics of an XML document will bedefined either by the applications that process them or by stylesheets.

[0032] As the Internet becomes a serious business tool, HTML'slimitations are becoming more apparent. For example, HTML can be used toexchange data, but it is not capable of exchanging objects. To be moreprecise, HTML cannot be used to exchange serialized objects.

[0033] XML does not have defined protocol for exchanging serializedobjects between computers within a distributed computing environment.

SUMMARY

[0034] The object persister serializes an object to preserve theobject's data structure and its current data. The serialized object isencoded using XML and inserted within a message. That message istransmitted to an entity over a network. Such a transmission isperformed using standard Internet protocols, such as HTML. Uponreceiving the serialized object, the receiving entity deserializes theobject to use it.

[0035] Rather than include copies of referenced objects within theserialized object, the object persister includes references to thoseobjects. This avoids redundant inclusion of the same object andpotentially infinite inclusion of the object itself that is beingserialized.

BRIEF DESCRIPTION OF THE DRAWINGS

[0036]FIG. 1 is a schematic illustration of an exemplary computernetwork (such as the Internet) that includes two computer entities.

[0037]FIG. 2a is a textual illustration of a typical data structure ofan object as represented in pseudocode.

[0038]FIG. 2b is a textual illustration of a serialized object generatedby an implementation of the exemplary object persister, where thetypical data structure shown in FIG. 2a is the base object that wasserialized.

[0039]FIG. 3 is flowchart showing a process implementing the exemplaryobject persister.

[0040]FIG. 4 is an example of a computer capable of implementing theexemplary object persister.

DETAILED DESCRIPTION

[0041] The following description sets forth a specific embodiment of theobject persister that incorporates elements recited in the appendedclaims. This embodiment is described with specificity in order to meetstatutory written description, enablement, and best-mode requirements.However, the description itself is not intended to limit the scope ofthis patent. Rather, the inventors have contemplated that the claimedobject persister might also be embodied in other ways, in conjunctionwith other present or future technologies.

[0042] Computer Entities and Object Exchange

[0043]FIG. 1 shows two computers 22, 24. These computers are connectedto each other via a computer network 26. These computers may be desktop,laptop, handheld, server, or mainframe computers. These computers may bea computer capable of connecting to a communications network andexchanging messages. More particularly, a message comprises at least oneserialized object. The network 26 may be a private network (e.g., alocal or wide area network) or a public network (e.g., the Internet).

[0044] Herein, an entity is understood to be a computer component thatis capable of exchanging messages containing at least one serializedobject with another entity. Such an entity may be in an object-oriented,decentralized, distributed network environment. Alternatively, such anentity may be in a local, object-oriented computing environment. Forexample, an entity may be a computer, a computer system, a component ofa computer, or an application running on a computer.

[0045] Herein, an originating entity (i.e., originator) is an entitythat serialized an object, inserts it into a message, and sends thatmessage. A destination entity (i.e., ultimate destination) is an entitythat receives the message, parses the message, and deserializes theserialized object in the message. The exemplary object persister isimplemented by one or more computer entities within a local computingenvironment or within a distributed network environment.

[0046] SOAP

[0047] In the primary exemplary embodiment described herein, the objectpersister is implemented as part of a protocol called Simple ObjectAccess Protocol (SOAP). In addition, the primary exemplary embodimentdescribed herein employs XML (eXtensible Markup Language).

[0048] SOAP provides a simple and lightweight mechanism for exchangingstructured and typed information between peers in a decentralized,distributed environment using XML. SOAP does not itself define anyapplication semantics such as a programming model or implementationspecific semantics; rather it defines a simple mechanism for expressingapplication semantics by providing a modular packaging model and anencoding mechanism for encoding data within modules. This allows SOAP tobe used in a large variety of systems ranging from general messagingsystems to object-oriented programming systems to Remote Procedure Calls(RPC).

[0049] SOAP consists of two parts:

[0050] The SOAP envelope construct defines an overall framework forexpressing what is in a message; who should deal with it, and whether itis optional or mandatory.

[0051] The SOAP encoding mechanism defines a serialization mechanism forexchange of application-defined datatypes.

[0052] The SOAP envelope portion (which may be called the “messageexchanger”) is described in more detail in appendix A and in co-pendingpatent application, entitled “Messaging Method, Apparatus, and Articleof Manufacture”, which was filed Apr. 27, 2000 and is assigned to theMicrosoft Corporation. The co-pending application is incorporated byreference.

[0053] The SOAP encoding mechanism includes the primarily exemplaryembodiment of an object persister described herein. Furthermore, SOAP isdescribed in more detail in Appendix A.

[0054] XML and HTTP

[0055] Unlike HTML (HyperText Markup Language), XML has sufficientflexibility so that it is possible to exchange serialized objects over anetwork. XML has no standard mechanism to accomplish this. However, theexemplary object persister provides such a mechanism to accomplish this.

[0056] Using the exemplary object persister, an object is serialized andencoded into XML and sent over a network to a destination entity. Withthe exemplary object persister, the serialized object is inserted into amessage and sent over a network using HTTP (HyperText TransportProtocol). However, other transport protocols may be employed.

[0057] Serialization Format

[0058] The elements in the serialization format of the exemplary objectpersister represent different elements in an object data structure. Theformat is easily readable by humans and machines. The format alsocompensates for potentially infinite cycles where objects call eachother.

[0059] In FIG. 2a, a data structure 30 of an exemplary object is shown.This is only an example and those of ordinary skill in the art willunderstand that an object can have nearly an infinite number ofarrangements and labels. Data structure 30 is merely an example of onepossible arrangement and labels. The object is called “Object_label” at32. The data structure includes various parameters such as those shownat 34, 36, and 38.

[0060] A parameter may be one of many “datatypes” or “types”. Datatypeis a concept understood by those of ordinary skill in the art. There aretwo main forms of datatypes: simple and complex.

[0061] A parameter is a simple datatype when it is defined to be a mostfundamental type of data. In other words, a simple datatype cannot bebroken down into one or more simpler types. Examples of a simple datatype include character, string, integer, and floating point.

[0062] A parameter is a complex datatype when it composed of one or moreother datatypes, which may include simple and other complex datatypes. Acomplex datatype may also be a customized datatype, which is definedwithin the object or by a reference to a definition outside of theobject.

[0063] In FIG. 2a, parameters 34 are simple datatypes. Param1_label andparam2 are strings. Param3_label is an integer. Parameter 36 defines thename of another object called “ObjectName” and provides is memoryaddress at “*memorylocation.” This parameter includes another objectwithin the data structure of the main object by naming it and providingits address.

[0064] The object's data structure also includes a parameter that isitself a data structure at 38. This data structure parameter definesadditional parameters. In particular, the addition parameters includeparamA_label (an integer), paramB_label (a floating point), andparamC_label (a string).

[0065]FIG. 2b illustrates a serialized representation of the exemplaryobject shown in FIG. 2a that may be generated by the exemplary objectpersister. In addition to preserving the parameter labels and hieraticalstructure of the object in FIG. 2a, the exemplary object persisterpreserves the current “status” of the object at a moment in time. The“status” of the object is represented by the data actually stored withinthe data structure of the object at the moment that the object isserialized.

[0066] As discussed above (and shown in Appendix A), the serializedobject of the exemplary object persister is sent within a message over anetwork. FIG. 2b shows the XML tags (“<Bodylabel>” and “</Bodylabel>”)used to define the boundaries of the body of a message. The serializedobject is typically inserted inside the body.

[0067]FIG. 2b shows the XML tags (“<Object_label>” at 54 a and“</Objectlabel>” at 54 b) that define the boundaries of the datastructure of the serialized object (of FIG. 2a). Note that the same name“Object_label” is used in the label 32 of FIG. 2a and in the tags 54 a,54 b of FIG. 2b.

[0068] Corresponding to the parameters 34 of FIG. 2a are serializedparameters 56 in FIG. 2b. Each parameter has a pair of tags that definethe boundaries of the parameter. For example, “param2_label” has abeginning tag <param2_label> and an ending label </param2_label>.Between these tags is the serialized data of the parameter that wassaved at the moment the object was serialized. For example, param3_labelis an integer data type (see parameters 34 of FIG. 2a); therefore, data3(in parameters 56 of FIG. 2b) may be any integer such as “43.”

[0069] In FIG. 2b, none of the datatypes of the parameters is shown ordefined. The datatypes may be defined internally or externally. Internaldefinition describes when datatype definitions for each parameter arespecified within the message containing the serialized object. Externaldefinition describes when datatype definitions for each parameter arespecified outside of the message, but the message contains one or morereferences to the location where the definitions are located.

[0070]FIG. 2b also shows a reference to another object at 58. In thisparameter, an object called “ObjectName” is specified and it is locatedby a reference label “object2_ref”. Rather than including a copy of the“ObjectName” object within the serialized object, the exemplarypersister simply includes the reference to the object. Referencing ofembedded objects instead of including them lessens the data that must beserialized and sent over a network.

[0071] The object being serialized may be quite large and includeredundant information if it includes multiple references to anotherobject or if a referenced object includes references to still otherobjects. Suppose, for example, an object being serialized includesreferences to ObjectA, ObjectB, ObjectC, ObjectD, and ObjectE. ObjectBincludes references to ObjectD and ObjectE. In addition, ObjectEincludes references to ObjectsA-D. If all referenced objects wereincluded within the serialized object (as is conventional), then most ofthe referenced object would be included multiple times. This isredundant. The exemplary object persister avoids this problem byincluding references to an object rather than the object itself.

[0072] Furthermore, the serialization of an object may be stuck aninfinite loop if the object includes a references to itself or if areferenced object refers back to the object being serialized. If theserialization process includes the referenced object within theserialized object (as is conventional), then the serialized object mayinclude itself in itself in itself in itself in itself etc. Theexemplary object persister avoids this problem by including referencesto an object rather than the object to itself. Thus, an object willsimply include a reference to itself.

[0073] In FIG. 2b, the serialized object also includes a parameter thatis a data structure at 62. This data structure parameter is bounded by apair of XML tags, “<DataStruct_label>” at 60 a and “</DataStruct_label>”at 60 b.

[0074] The serialized object bounded by tags 54 a and 54 b may also becalled a data structure element or simply “datastruct” element. The tagsare part of the datastruct element. Everything within these tags iscontent of the datastruct element. The parameters (such as 56, 58, and62) are part of the contents of the datastruct element.

[0075] Serialization Example

[0076] Below is an example of serialization of an object. The exemplaryobject's data structure in pseudocode: Struct StockQuote {  stringcompany;  string stocksymbol;  int annual_high;  int annual_low;  intcurrent_price; }

[0077] Below is a serialized representation of an object (based upon theabove structure is pseudocode) generated in accordance with theexemplary object persister: <StockQuote>  <company> CompanyX </company> <stocksymbol> CPYX </stocksymbol>  <annual_high> 101 </annual high> <annual_low> 72 </annual_low>  <current_price> 93 </current_price></StockQuote>

[0078] Exemplary Methodological Implementation of the Object Persister

[0079]FIG. 3 shows an exemplary methodological implementation of theobject persister. At 100, the object serialization is initiated. Thismay be the result of a specific manual command or an automatic commandof another program or object. If an object is being sent from anoriginating entity (such as entity 22 in FIG. 1) to a destination entity(such as entity 24 in FIG. 1), then the object must be serialized. Thus,serialization may be initiated by a request from the destination entityfor the object.

[0080] At 102 of FIG. 3, the object is serialized in the mannergenerally described above in the Serialization Format section. Morespecifically, a datastruct element is generated with contents. Thisdatastruct element represents and preserves the hierarchicalorganization of the object data structure. The datastruct element isbounded by a pair of datastuct tags (such as tags 54 a and 54 b of FIG.2b). The contents are inside the tags.

[0081] The contents of the data struct element include one or more dataparameter elements (such as parameters 56, 58, and 62 in FIG. 2b). Eachdata parameter element represents and preserves the organization andlabel of the parameters of the object. Each parameter element is boundedby a pair of parameter tags (such as “<param2_label>” and“</param2_label>” of the first parameter in the parameters 56 in FIG.2b). Between each pair of parameter tag is data that represents thevalue of that parameter when that object was serialized. The datatypesof the parameters are defined either internally or externally.

[0082] At 104 of FIG. 3, the datastruct element is inserted into thebody of a message. At 106, the message is sent from the originatingentity to the destination entity via a network. In the exemplary objectpersister, the message may be sent over the Internet using the HTTPprotocol.

[0083] At 108 and 110, the destination entity receives the message andparses it. At 112, the serialized object in the message is deserialized.The new object has the same hierarchical structure and arrangement ofthe original object (that was serialized). It also includes the data ofthat object at the moment that the object was serialized.

[0084] Exemplary Computing Environment

[0085]FIG. 4 illustrates an example of a suitable computing environment920 on which the exemplary object persister may be implemented.

[0086] Exemplary computing environment 920 is only one example of asuitable computing environment and is not intended to suggest anylimitation as to the scope of use or functionality of the exemplaryobject persister. Neither should the computing environment 920 beinterpreted as having any dependency or requirement relating to any oneor combination of components illustrated in the exemplary computingenvironment 920.

[0087] The exemplary object persister is operational with numerous othergeneral purpose or special purpose computing system environments orconfigurations. Examples of well known computing systems, environments,and/or configurations that may be suitable for use with the exemplaryobject persister include, but are not limited to, personal computers,server computers, think clients, thick clients, hand-held or laptopdevices, multiprocessor systems, microprocessor-based systems, set topboxes, programmable consumer electronics, network PCs, minicomputers,mainframe computers, distributed computing environments that include anyof the above systems or devices, and the like.

[0088] The exemplary object persister may be described in the generalcontext of computer-executable instructions, such as program modules,being executed by a computer. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data types.The exemplary object persister may also be practiced in distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed computing environment, program modules may be located inboth local and remote computer storage media including memory storagedevices.

[0089] As shown in FIG. 4, the computing environment 920 includes ageneral-purpose computing device in the form of a computer 930. Thecomponents of computer 920 may include, by are not limited to, one ormore processors or processing units 932, a system memory 934, and a bus936 that couples various system components including the system memory934 to the processor 932.

[0090] Bus 936 represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. By way of example, and notlimitation, such architectures include Industry Standard Architecture(ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA)bus, Video Electronics Standards Association (VESA) local bus, andPeripheral Component Interconnects (PCI) buss also known as Mezzaninebus.

[0091] Computer 930 typically includes a variety of computer readablemedia. Such media may be any available media that is accessible bycomputer 930, and it includes both volatile and non-volatile media,removable and non-removable media.

[0092] In FIG. 4, the system memory includes computer readable media inthe form of volatile memory, such as random access memory (RAM) 940,and/or non-volatile memory, such as read only memory (ROM) 938. A basicinput/output system (BIOS) 942, containing the basic routines that helpto transfer information between elements within computer 930, such asduring start-up, is stored in ROM 938. RAM 940 typically contains dataand/or program modules that are immediately accessible to and/orpresently be operated on by processor 932.

[0093] Computer 930 may further include other removable/non-removable,volatile/non-volatile computer storage media. By way of example only,FIG. 4 illustrates a hard disk drive 944 for reading from and writing toa non-removable, non-volatile magnetic media (not shown and typicallycalled a “hard drive”), a magnetic disk drive 946 for reading from andwriting to a removable, non-volatile magnetic disk 948 (e.g., a “floppydisk”), and an optical disk drive 950 for reading from or writing to aremovable, non-volatile optical disk 952 such as a CD-ROM, DVD-ROM orother optical media. The hard disk drive 944, magnetic disk drive 946,and optical disk drive 950 are each connected to bus 936 by one or moreinterfaces 954.

[0094] The drives and their associated computer-readable media providenonvolatile storage of computer readable instructions, data structures,program modules, and other data for computer 930. Although the exemplaryenvironment described herein employs a hard disk, a removable magneticdisk 948 and a removable optical disk 952, it should be appreciated bythose skilled in the art that other types of computer readable mediawhich can store data that is accessible by a computer, such as magneticcassettes, flash memory cards, digital video disks, random accessmemories (RAMs), read only memories (ROM), and the like, may also beused in the exemplary operating environment.

[0095] A number of program modules may be stored on the hard disk,magnetic disk 948, optical disk 952, ROM 938, or RAM 940, including, byway of example, and not limitation, an operating system 958, one or moreapplication programs 960, other program modules 962, and program data964.

[0096] A user may enter commands and information into computer 930through input devices such as keyboard 966 and pointing device 968 (suchas a “mouse”). Other input devices (not shown) may include a microphone,joystick, game pad, satellite dish, serial port, scanner, or the like.These and other input devices are connected to the processing unit 932through an user input interface 970 that is coupled to bus 936, but maybe connected by other interface and bus structures, such as a parallelport, game port, or a universal serial bus (USB).

[0097] A monitor 972 or other type of display device is also connectedto bus 936 via an interface, such as a video adapter 974. In addition tothe monitor, personal computers typically include other peripheraloutput devices (not shown), such as speakers and printers, which may beconnected through output peripheral interface 975.

[0098] Computer 930 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer982. Remote computer 982 may include many or all of the elements andfeatures described herein relative to computer 930.

[0099] Logical connections shown in FIG. 4 are a local area network(LAN) 977 and a general wide area network (WAN) 979. Such networkingenvironments are commonplace in offices, enterprise-wide computernetworks, intranets, and the Internet.

[0100] When used in a LAN networking environment, the computer 930 isconnected to LAN 977 network interface or adapter 986. When used in aWAN networking environment, the computer typically includes a modem 978or other means for establishing communications over the WAN 979. Themodem 978, which may be internal or external, may be connected to thesystem bus 936 via the user input interface 970, or other appropriatemechanism.

[0101] Depicted in FIG. 4, is a specific implementation of a WAN via theInternet. Over the Internet, computer 930 typically includes a modem 978or other means for establishing communications over the Internet 980.Modem 978, which may be internal or external, is connected to bus 936via interface 970.

[0102] In a networked environment, program modules depicted relative tothe personal computer 930, or portions thereof, may be stored in aremote memory storage device. By way of example, and not limitation,FIG. 4 illustrates remote application programs 989 as residing on amemory device of remote computer 982. It will be appreciated that thenetwork connections shown and described are exemplary and other means ofestablishing a communications link between the computers may be used.

[0103] Exemplary Operating Environment

[0104]FIG. 4 illustrates an example of a suitable operating environment920 in which the exemplary object persister may be implemented.Specifically, the exemplary object persister is implemented by anyprogram 960-962 or operating system 958 in FIG. 4.

[0105] The operating environment is only an example of a suitableoperating environment and is not intended to suggest any limitation asto the scope of use of functionality of the bw-meter described herein.Other well known computing systems, environments, and/or configurationsthat may be suitable for use with the bw-meter include, but are notlimited to, personal computers, server computers, hand-held or laptopdevices, multiprocessor systems, microprocessor-based systems,programmable consumer electronics, network PCs, minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices, and the like.

[0106] Computer-Executable Instructions

[0107] An implementation of the exemplary object persister may bedescribed in the general context of computer-executable instructions,such as program modules, executed by one or more computers or otherdevices. Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Typically, the functionalityof the program modules may be combined or distributed as desired invarious embodiments.

[0108] Computer Readable Media

[0109] An implementation of the exemplary object persister may be storedon or transmitted across some form of computer readable media. Computerreadable media can be any available media that can be accessed by acomputer. By way of example, and not limitation, computer readable mediamay comprise computer storage media and communications media.

[0110] Computer storage media include volatile and non-volatile,removable and non-removable media implemented in any method ortechnology for storage of information such as computer readableinstructions, data structures, program modules, or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical storage, magnetic cassettes, magnetic tape, magneticdisk storage or other magnetic storage devices, or any other mediumwhich can be used to store the desired information and which can beaccessed by a computer.

[0111] Communication media typically embodies computer readableinstructions, data structures, program modules, or other data in amodulated data signal such as carrier wave or other transport mechanismand included any information delivery media. The term “modulated datasignal” means a signal that has one or more of its characteristics setor changed in such a manner as to encode information in the signal. Byway of example, and not limitation, communication media includes wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, RF, infrared, and other wireless media.Combinations of any of the above are also included within the scope ofcomputer readable media.

[0112] Conclusion

[0113] Although the object persister has been described in languagespecific to structural features and/or methodological steps, it is to beunderstood that the object persister defined in the appended claims isnot necessarily limited to the specific features or steps described.Rather, the specific features and steps are disclosed as preferred formsof implementing the claimed object persister.

[0114] Appendix A

[0115] Appendix A includes a copy of a provisional application filed onMar. ______, 2000 and submitted to W3C organization for considerationstandards committee.

[0116] SOAP: Simple Object Access Protocol

[0117] W3C Technical Report 23 March 2000

[0118] Abstract

[0119] SOAP is a lightweight protocol for exchange of information indecentralized, distributed environments. It is an XML based protocolthat consists of two parts: an envelope for handling extensibility andmodularity and an encoding mechanism for representing types within theenvelope. SOAP can potentially be used in combination with a variety ofother protocols; however, the only bindings defined in this documentdescribe how to use SOAP in combination with HTTP and HTTP ExtensionFramework.

[0120] Introduction

[0121] SOAP provides a simple and lightweight mechanism for exchangingstructured and typed information between peers in a decentralized,distributed environment using XML. SOAP does not itself define anyapplication semantics such as a programming model or implementationspecific semantics; rather it defines a simple mechanism for expressingapplication semantics by providing a modular packaging model and anencoding mechanism for encoding data within modules. This allows SOAP tobe used in a large variety of systems ranging from messaging systems toRPC.

[0122] SOAP consists of two parts:

[0123] The SOAP envelope construct defines an overall framework forexpressing what is in a message; who should deal with it, and whether itis optional or mandatory.

[0124] The SOAP encoding mechanism defines a serialization mechanism forexchange of application-defined datatypes.

[0125] Although the envelope and the encoding both are an integral partof SOAP they are functionally orthogonal and are defined in differentnamespaces in order to promote simplicity through modularity.

[0126] In addition to the SOAP envelope and encoding, this specificationdefines two protocol bindings that describe how a SOAP message can becarried in HTTP messages either with or without the HTTP ExtensionFramework.

[0127] Notational Conventions

[0128] The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALLNOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” inthis document are to be interpreted as described in RFC-2119 [2].

[0129] The namespace prefixes “SOAP-ENV” and “SOAP-ENC” are used in thisdocument to represent the prefixes that actually appears in the XMLinstance and are associated with the SOAP namespaces“http://schemas.xmlsoap.org/soap/envelope/” and“http://schemas.xmlsoap.org/soap/encoding/” respectively.

[0130] Throughout this document, the namespace prefix “xsi” is assumedto be associated with the URI“http://www.w3.org/1999/XMLSchema/instance” which is defined in the XMLSchemas specification [11].

[0131] Namespace URIs of the general form “some-URI” represent someapplication-dependent or context-dependent URI [4].

[0132] This specification uses the augmented Backus-Naur Form (ABNF) asdescribed in RFC-2234 [3] for certain constructs.

[0133] Examples of SOAP Messages

[0134] In this example, a GetLastTradePrice SOAP request is sent to aStockQuote service. The request takes a string parameter, ticker, andreturns a float in the SOAP response. The SOAP Envelope element is thetop element of the XML document representing the SOAP message. XMLnamespaces are used to disambiguate SOAP identifiers from applicationspecific identifiers. The example illustrates the HTTP bindings. It isworth noting that the rules governing XML payload format in SOAP areentirely independent of the fact that the payload is carried in HTTP.

[0135] Example 1 SOAP Message Embedded in HTTP Request   POST/StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type:text/xml Content-Length: nnnn SOAPAction: “Some-URI” <SOAP-ENV: Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”  SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”>  <SOAP-ENV:Body>    <m:GetLastTradePrice xmlns:m=“Some-URI”>    <symbol>DIS</symbol>    </m:GetLastTradePrice>   </SOAP-ENV:Body></SOAP-ENV:Envelope>

[0136] Following is the response message containing the HTTP messagewith the SOAP message as the payload:

[0137] Example 2 SOAP Message Embedded in HTTP Response   HTTP/1.1 200OK Content-Type: text/xml Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”  SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/> <SOAP-ENV:Body>   <m:GetLastTradePriceResponse xmlns:m=“Some-URI”>   <Price>34.5</Price>   </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

[0138] The SOAP Message Exchange Model

[0139] SOAP does not define a specific message exchange pattern, as thisis defined by the protocol bindings to a specific protocol such as HTTP.In other words, SOAP itself is not a request/response or a one-waymessage protocol. However, it can be used within the context of arequest/response protocol or a one-way message protocol. For example, inthe context of HTTP, SOAP inherits the HTTP message exchange pattern ofrequests and responses.

[0140] SOAP does however define the notion of a message path thatconsists of the originator of the message, the ultimate destination, andpotentially one or more intermediaries that may take part in the messagepath.

[0141] A SOAP application receiving a SOAP message MUST process thatmessage by performing the following actions in the order listed below:

[0142] 1. Identify all parts of the SOAP message intended for thatapplication

[0143] 2. Verify that all mandatory parts identified in step 1 aresupported by the application for this message and process themaccordingly. If this is not the case then discard the message. Theprocessor MAY ignore optional parts identified in step 1 withoutaffecting the outcome of the processing.

[0144] 3. If the SOAP application is not the ultimate destination of themessage then remove all parts identified in step 1 before forwarding themessage.

[0145] 2. 3. Relation to XML

[0146] All SOAP messages are encoded using XML.

[0147] A SOAP application SHOULD include the proper SOAP namespace onall elements and attributes defined by SOAP in messages that itgenerates. A SOAP application MUST be able to process SOAP namespaces inmessages that it receives. It MUST discard messages that have incorrectnamespaces and it MAY process SOAP messages without SOAP namespaces asthough they had the correct SOAP namespaces.

[0148] SOAP defines two namespaces:

[0149] The SOAP envelope has the namespace identifier“http://schemas.xmlsoap.org/soap/envelope/”

[0150] The SOAP serialization has the namespace identifier“http://schemas.xmlsoap.org/soap/encoding/”

[0151] SOAP uses the local, unqualified “id” attribute of type “ID” tospecify the unique identifier of an encoded element. SOAP uses thelocal, unqualified attribute “href” of type “uri-reference” to specify areference to that value, in a manner conforming to the XML Specification[7], XML Schema Specification [11], and XML Linking LanguageSpecification [21].

[0152] With the exception of the SOAP mustUnderstand attribute and theSOAP actor attribute, it is generally permissible to have attributes andtheir values appear in XML instances or alternatively in schemas, withequal effect. That is, declaration in a DTD or schema with a default orfixed value is semantically equivalent to appearance in an instance.

[0153] SOAP Envelope

[0154] A SOAP message is an XML document that consists of a mandatorySOAP envelope, an optional SOAP header, and a mandatory SOAP body. ThisXML document is referred to as a SOAP message for the rest of thisspecification. The namespace identifier for the elements and attributesdefined in this section is “http://schemas.xmlsoap.org/soap/envelope/”.A SOAP message contains the following:

[0155] The Envelope is the top element of the XML document representingthe message.

[0156] The Header is a generic mechanism for adding features to a SOAPmessage in a decentralized manner without prior agreement between thecommunicating parties. SOAP defines a few attributes that can be used toindicate who should deal with a feature and whether it is optional ormandatory.

[0157] The Body is a container for mandatory information intended forthe ultimate recipient of the message. SOAP defines one element for thebody, which is the Fault element used for reporting errors.

[0158] The grammar rules are as follows:

[0159] 1. Envelope

[0160] The element name is “Envelope”.

[0161] The element MUST be present in a SOAP message

[0162] The element MAY contain namespace declarations as well asadditional attributes. If present, such additional attributes MUST benamespace-qualified. Similarly, the element MAY contain additional subelements. If present these elements MUST be namespace-qualified and MUSTfollow the SOAP Body element.

[0163] 2. Header

[0164] The element name is “Header”.

[0165] The element MAY be present in a SOAP message. If present, theelement MUST be the first immediate child element of the SOAP Envelopeelement.

[0166] The element MAY contain a set of header entries each being animmediate child element of the SOAP Header element. All immediate childelements of the SOAP Header element MUST be namespace-qualified.

[0167] 3. Body

[0168] The element name is “Body”.

[0169] The element MUST be present in a SOAP message and MUST be animmediate child element of the SOAP Envelope element. It MUST directlyfollow the SOAP Header element if present. Otherwise it MUST be thefirst immediate child element of the SOAP Envelope element.

[0170] The element MAY contain a set of body entries each being animmediate child element of the SOAP Body element. Immediate childelements of the SOAP Body element MAY be namespace-qualified. SOAPdefines the SOAP Fault element, which is used to indicate errormessages.

[0171] SOAP encodingStyle Attribute

[0172] The SOAP encodingStyle global attribute can be used to indicatethe serialization rules used in a SOAP message. This attribute MAYappear on any element, and is scoped to that element's contents and allchild elements not themselves containing such an attribute, much as anXML namespace declaration is scoped. There is no default encodingdefined for a SOAP message.

[0173] The attribute value is an ordered list of one or more URIsidentifying the serialization rule or rules that can be used todeserialize the SOAP message indicated in the order of most specific toleast specific. Examples of values are  “http://schemas.xmlsoap.org/soap/encoding/”“http://my.host/encoding/restricted http://my.host/encoding/” “ ”

[0174] The serialization rules defined by SOAP are identified by the URI“http://schemas.xmlsoap.org/soap/encoding/”. Messages using thisparticular serialization SHOULD indicate this using the SOAPencodingStyle attribute. In addition, all URIs syntactically beginningwith “http://schemas.xmlsoap.org/soap/encoding//” indicate conformancewith the SOAP encoding rules.

[0175] A value of the zero-length URI (“”) explicitly indicates that noclaims are made for the encoding style of contained elements. This canbe used to turn off any claims from containing elements.

[0176] Envelope Versioning Model

[0177] SOAP does not define a traditional versioning model based onmajor and minor version numbers. A SOAP message MUST have an Envelopeelement associated with the “http://schemas.xmlsoap.org/soap/envelope/”namespace. If a message is received by a SOAP application in which theSOAP Envelope element is associated with a different namespace, theapplication MUST treat this as a version error and discard the message.If the message is received through a request/response protocol such asHTTP, the application MUST respond with a SOAP VersionMismatch faultcodemessage using the SOAP “http://schemas.xmlsoap.org/soap/envelope/”namespace.

[0178] SOAP Header

[0179] SOAP provides a flexible mechanism for extending a message in adecentralized and modular way without prior knowledge between thecommunicating parties. Typical examples of extensions that can beimplemented as header entries are authentication, transactionmanagement, payment etc.

[0180] The Header element is encoded as the first immediate childelement of the SOAP Envelope XML element. All immediate child elementsof the Header element are called header entries.

[0181] The encoding rules for header entries are as follows:

[0182] 1. A header entry is identified by its fully qualified elementname, which consists of the namespace URI and the local name. Allimmediate child elements of the SOAP Header element MUST benamespace-qualified.

[0183] 2. The SOAP encodingStyle attribute MAY be used to indicate theencoding style used for the header entries.

[0184] 3. The SOAP mustUnderstand attribute and SOAP actor attribute MAYbe used to indicate how to process the entry and by whom.

[0185] Use of Header Attributes

[0186] The SOAP Header attributes defined in this section determine howa recipient of a SOAP message should process the message. A SOAPapplication generating a SOAP message SHOULD only use the SOAP Headerattributes on immediate child elements of the SOAP Header element. Therecipient of a SOAP message MUST ignore all SOAP Header attributes thatare not applied to an immediate child element of the SOAP Headerelement.

[0187] An example is a header with an element identifier of“Transaction”, a “mustUnderstand” value of “1”, and a value of 5. Thiswould be encoded as follows:   <SOAP-ENV:Header>  <t:Transaction  xmlns:t=“some-URI” SOAP-ENV:mustUnderstand=“1”>    5  </t:Transaction> </SOAP-ENV:Header>

[0188] SOAP Actor Attribute

[0189] A SOAP message travels from the originator to the ultimatedestination, potentially by passing through a set of SOAP intermediariesalong the message path. A SOAP intermediary is an application that iscapable of both receiving and forwarding SOAP messages. Bothintermediaries as well as the ultimate destination are identified by aURI.

[0190] Not all parts of a SOAP message may be intended for the ultimatedestination of the SOAP message but may be intended for one or more ofthe intermediaries on the message path. The role of a recipient of aheader element is similar to that of accepting a contract in that itcannot be extended beyond the recipient. That is, a recipient receivinga header element MUST NOT forward that header element to the nextapplication in the SOAP message path. The recipient MAY insert a similarheader element but in that case, the contract is between thatapplication and the recipient of that header element.

[0191] The SOAP actor global attribute can be used to indicate therecipient of a header element. The value of the SOAP actor attribute isa URI. The special URI “http://schemas.xmlsoap.org/soap/actor/next”indicates that the header element is intended for the very first SOAPapplication that processes the message. This is similar to thehop-by-hop scope model represented by the Connection header field inHTTP.

[0192] Omitting the SOAP actor attribute indicates that the sender doesnot know or does not care which resource should process the headerelement. The SOAP actor global header element attribute can be used toindicate the entity that is going to act on that header element. Theentity identified by the SOAP actor can be thought of as the applicationresource that a header element is intended for. This can for example beused to indicate whether a header element is intended for an entity ofthe recipient that takes part of the application or as part of therouting infrastructure.

[0193] This attribute MUST appear in the SOAP message instance and notin a schema or DTD in order to be effective.

[0194] SOAP mustUnderstand Attribute

[0195] The SOAP mustUnderstand global attribute can be used to indicatewhether a header entry is mandatory or optional for the recipient toprocess. The recipient of a header entry is defined by the SOAP actorattribute. The value of the mustUnderstand attribute is either “1” or“0”. The absence of the SOAP mustUnderstand attribute is semanticallyequivalent to its presence with the value “0”.

[0196] If a header element is tagged with a SOAP mustUnderstandattribute with a value of “1”, the recipient of that header entry eitherMUST obey the semantics (as conveyed by its element name, contextualsetting, and so on) and process correctly to those semantics, or MUSTfail processing the message.

[0197] The SOAP mustUnderstand attribute allows for robust evolution.Elements tagged with the SOAP mustUnderstand attribute with a value of“1” MUST be presumed to somehow modify the semantics of their parent orpeer elements. Tagging elements in this manner assures that this changein semantics will not be silently (and, presumably, erroneously) ignoredby those who may not fully understand it.

[0198] This attribute MUST appear in the instance and not in a schema orDTD in order to be effective.

[0199] SOAP Body

[0200] The SOAP Body element provides a simple mechanism for exchangingmandatory information intended for the ultimate recipient of themessage. Typical uses of the Body element include marshalling RPC callsand error reporting.

[0201] The Body element is encoded as an immediate child element of theSOAP Envelope XML element. If a Header element is present then the Bodyelement MUST immediately follow the Header element, otherwise it MUST bethe first immediate child element of the Envelope element.

[0202] All immediate child elements of the Body element are called bodyentries and each body entry is encoded as an independent element withinthe SOAP Body element.

[0203] The encoding rules for body entries are as follows:

[0204] 1. A body entry is identified by its fully qualified elementname, which consists of the namespace URI and the local name. Immediatechild elements of the SOAP Body element MAY be namespace-qualified.

[0205] 2. The SOAP encodingStyle attribute MAY be used to indicate theencoding style used for the body entries.

[0206] SOAP defines one body entry, which is the Fault entry used forreporting errors.

[0207] Relationship between SOAP Header and Body

[0208] While the Header and Body are defined as independent elements,they are in fact related. The relationship between a body entry and aheader entry is as follows: A body entry is semantically equivalent to aheader entry intended for the default actor and with a SOAPmustUnderstand attribute with a value of “1”. The default actor isindicated by not using the actor attribute.

[0209] SOAP Fault

[0210] The SOAP Fault element is used to carry error and/or statusinformation within a SOAP message. If present, the SOAP Fault elementMUST appear as a body entry and MUST NOT appear more than once within aBody element. The SOAP Fault element defines the following foursubelements:

[0211] faultcode

[0212] The faultcode element is intended for use by software to providean algorithmic mechanism for identifying the fault. The faultcode MUSTbe present in a SOAP Fault element and the faultcode value MUST be aqualified name. SOAP defines a small set of SOAP fault codes coveringbasic SOAP faults.

[0213] faultstring

[0214] The faultstring element is intended to provide a human readableexplanation of the fault and is not intended for algorithmic processing.The faultstring element is similar to the ‘Reason-Phrase’ defined byHTTP (see [5]). It MUST be present in a SOAP Fault element and SHOULDprovide at least some information explaining the nature of the fault.

[0215] faultactor

[0216] The faultactor element is intended to provide information aboutwho caused the fault to happen within the message path. It is similar tothe SOAP actor attribute but instead of indicating the destination ofthe header entry, it indicates the source of the fault. The value of thefaultactor attribute is a URI identifying the source. Applications thatdo not act as the ultimate destination of the SOAP message MUST includethe faultactor element in a SOAP Fault element. The ultimate destinationof a message MAY use the faultactor element to indicate explicitly thatit generated the fault.

[0217] detail

[0218] The detail element is intended for carrying application specificerror information related to the Body element. It MUST be present if thecontents of the Body element could not be successfully processed. ItMUST NOT be used to carry information about error information belongingto header entries. Detailed error information belonging to headerentries MUST be carried within header entries.

[0219] The absence of the detail element in the Fault element indicatesthat the fault is not related to processing of the Body element. Thiscan be used to distinguish whether the Body element was processed or notin case of a fault situation.

[0220] All immediate child elements of the detail element are calleddetail entries and each detail entry is encoded as an independentelement within the detail element.

[0221] The encoding rules for detail entries are as follows:

[0222] 1. A detail entry is identified by its fully qualified elementname, which consists of the namespace URI and the local name. Immediatechild elements of the detail element MAY be namespace-qualified.

[0223] 2. The SOAP encodingStyle attribute MAY be used to indicate theencoding style used for the detail entries.

[0224] Other Fault subelements MAY be present, provided they arenamespace-qualified.

[0225] SOAP Fault Codes

[0226] The faultcode values defined in this section MUST be used in thefaultcode element when describing faults defined by this specification.The namespace identifier for these faultcode values is“http://schemas.xmlsoap.org/soap/envelope/”. Use of this space isrecommended (but not required) in the specification of methods definedoutside of the present specification.

[0227] The default SOAP faultcode values are defined in an extensiblemanner that allows for new SOAP faultcode values to be defined whilemaintaining backwards compatibility with existing faultcode values. Themechanism used is very similar to the 1xx, 2xx, 3xx etc basic statusclasses classes defined in HTTP (see [5]). However, instead of integers,they are defined as XML qualified names (see [8]). The character “.”(dot) is used as a separator of faultcode values indicating that what isto the left of the dot is a more generic fault code value than the valueto the right. Example

[0228] Client.Authentication

[0229] The set of faultcode values defined in this document is: NameMeaning VersionMismatch The processing party found an invalid namespacefor the SOAP Envelope element MustUnderstand An immediate child elementof the SOAP Header element that was either not understood or not obeyedby the processing party contained a SOAP mustUnderstand attribute with avalue of “1”. Client The processing party could not process the messagebecause it was incorrectly formed or did not contain the appropriateinformation for the processing to succeed. Server The processing partywas incapable of processing the message.

[0230] SOAP Encoding

[0231] The SOAP encoding style uses a simple, traditional type system. Atype either is a simple (scalar) type or is a complex type constructedas a composite of several parts, each with a type. This section definesa rule for serialization of a graph of typed objects. The namespaceidentifier for the elements and attributes defined in this section is“http://schemas.xmlsoap.org/soap/encoding/”. The encoding samples shownassume all namespace declarations are at a higher element level.

[0232] Rules for Encoding Types in XML

[0233] XML allows very flexible encoding of data. SOAP defines anarrower set of rules for encoding. This section defines the encodingrules at a high level, and the next section describes the encoding rulesfor specific types when they require more detail.

[0234] To describe encoding, the following terminology is used:

[0235] 1. A “type” includes integer, string, point, street address, orsimilar. A type in SOAP corresponds to a scalar or structured type in aprogramming language or database. All values are of specific types.

[0236] 2. A “complex type” is one that has distinct, named parts andwhose encoding should reflect those named parts. A “simple type” is onewithout named parts. A structured type in a programming language is acomplex type, and so is an array.

[0237] 3. The name of a named part of a complex type is called an“accessor.”

[0238] 4. If only one accessor can reference it, a value is considered“single-reference” for a given schema. If referenced by more than one,actually or potentially in a given schema, it is “multi-reference.”Therefore, it is possible for a certain type to be considered“single-reference” in one schema and “multi-reference” in anotherschema.

[0239] 5. Syntactically, an element may be “independent” or “embedded.”An independent element is any element appearing at the top level of aserialization. All others are embedded elements.

[0240] The rules are as follows:

[0241] 1. Elements are used to reflect either accessors or instances oftypes. Embedded elements always reflect accessors. Independent elementsalways reflect instances of types. When reflecting an accessor, the nameof the element gives the name of the accessor. When reflecting aninstance of a type, the name of the element typically gives the name ofthe type (but see rule 11).

[0242] 2. A call or response/fault is always encoded as an independentelement.

[0243] 3. Accessors are always encoded as embedded elements.

[0244] 4. A value (simple or compound) is encoded as element content,either of an element reflecting an accessor to the value or of anelement reflecting an instance of that type.

[0245] 5. A simple value is encoded as character data, that is, withoutany sub elements according to Part II of the XML Schemas specification[11].

[0246] 6. Strings and byte arrays are multi-reference simple types, butspecial rules allow them to be represented efficiently for common cases.An accessor to a string or byte-array value MAY have an attribute named“id” and of type “ID” per the XML Specification [7]. If so, all otheraccessors to the same value are encoded as empty elements having alocal, unqualified attribute named “href” and of type “uri-reference”per the XML Schema Specifications [11], with the href containing a URIfragment identifier referencing the single element containing the value.

[0247] 7. It is permissible to encode several references to a simplevalue as though these were references to several single-referencevalues, but only when from context it is known that the meaning of theXML instance is unaltered.

[0248] 8. A complex value is encoded as a sequence of elements, eachnamed according to the accessor it reflects.

[0249] 9. A multi-reference simple or complex value is encoded as anindependent element containing a local, unqualified attribute named “id”and of type “ID” per the XML Specification [7]. Each accessor to thisvalue is an empty element having a local, unqualified attribute named“href” and of type “uri-reference” per the XML Schema Specifications[11], with the href containing a URI fragment identifier referencing thecorresponding independent element.

[0250] 10. Arrays are complex types. Arrays can be of one or moredimensions (rank) whose members are distinguished by ordinal position.An array value is represented as a series of elements reflecting thearray, with members appearing in ascending ordinal sequence; formulti-dimensional arrays the dimension on the right side varies mostrapidly. Arrays can be single-reference or multi-reference values. Asingle-reference embedded array is always encoded using an accessorelement whose type is “SOAP-ENC:Array”. A multi-reference array isalways encoded as an independent element whose type is “SOAP-ENC:Array”.The independent element or the accessor MUST contain a“SOAP-ENC:arrayType” attribute whose value specifies the type of thecontained elements and the dimensions of the array. This is encoded asthe type of the contained elements, as would appear in an xsi:typeattribute, followed by “[”, followed by comma-separated lengths of eachdimension, followed by “]”.The element type within theSOAP-ENC:ArrayType attribute acts as a type constraint (meaning thatelements of substitutable types may appear). Note that the containedelements in an array may themselves be arrays. In such cases the elementtype is an array type. An array type is encoded as the type of itscontained element, followed by “[”, followed by its rank encoded as asequence of commas (one for each dimension except the first), followedby “]”. The independent or accessor element containing an array valueMAY also contain a “SOAP-ENC:offset” attribute to indicate the startingposition of a partially represented array. Each contained element of anarray is encoded using the accessor named after its type (but see rule11) which MAY contain a “SOAP-ENC:position” attribute conveying theposition of that item in the enclosing array. Both “SOAP-ENC:offset” and'SOAP-ENC:position” attributes are encoded as “[”, followed by acomma-separated position in each dimension, followed by “]”, withoffsets and positions based at 0. Note that none of the forgoingprecludes an application storing data in an array and yet serializingthe value of that data as a series of elements not marked as aSOAP-ENC:Array nor employing the attributes just described.

[0251] 11. Any independent element or accessor element containing itsvalue directly MAY optionally have an attribute named “xsi:type” whosevalue indicates the type of the element's contained value as describedin “XML Schema Part 1: Structures” [10] and “XML Schema Part 2:Datatypes” [11]. However, its presence is mandatory on elements whosequalified element name does not clearly identify the type of theelement.

[0252] 12. A NULL value MAY be indicated by omission of the accessorelement. A NULL value MAY also be indicated by an accessor elementcontaining the attribute xsi:null=‘1’ and possibly otherapplication-dependent attributes and values.

[0253] Simple Types

[0254] For simple types, SOAP adopts the types found in the section“Built-in datatypes” of the “XML Schema Part 2: Datatypes” Specification[11], along with the corresponding recommended representation thereof.Examples include: Type Example integer  58502 real 314159265358979E+1negative-integer −32768

[0255] Strings and arrays of bytes are encoded as multi-reference simpletypes.

[0256] String

[0257] For the purposes of this encoding discussion, a “String” is anysequence of characters meeting the production for CharData in the XML1.0 specification. Note that many languages contain a datatype called“string” that permits values that do not match the CharData production.These values must be represented by using some datatype other thanxsi:string.

[0258] A string is a multi-reference simple type. According to the rulesof multi-reference simple types, the containing element of the stringvalue MAY have an ID attribute; additional accessor elements MAY thenhave matching href attributes.

[0259] For example, two accessors to the same string could appear, asfollows: <greeting id=“String-0”>Hello</greeting> <salutationhref=“#String-0”/>

[0260] However, if the fact that both accessors reference the sameinstance of the string is immaterial, they may be encoded as thoughsingle-reference, as follows: <greeting>Hello</greeting><salutation>Hello</salutation>

[0261] Enumerations

[0262] An enumeration is a single reference type whose value is encodedas one of the possible enumeration strings. In the following exampleEyeColor is an enumeration with the possible values of “Green”, “Blue”,or “Brown”: <Person>   <Name>Henry Ford</Name>   <Age>32</Age>   <EyeColor>Brown</EyeColor> </Person>

[0263] Array of Bytes

[0264] An array of bytes is encoded as a multi-reference simple type.The recommended representation of an opaque array of bytes is the‘base64’ encoding defined in XML Schemas [10][11], which uses the base64encoding algorithm defined in 2045 [13]. However, the line lengthrestrictions that normally apply to Base64 data in MIME do not apply inSOAP. <picture xsi:type=“SOAP-ENC:Base64”>  aG93IG5vDyBicm73biBjb3cNCg== </picture>

[0265] Polymorphic Accessor

[0266] Many languages allow accessors that can polymorphically accessvalues of several types, each type being available at run time. Apolymorphic accessor MUST contain an “xsi:type” attribute that describesthe type of the actual value.

[0267] For example, a Polymorphic parameter named “cost” with a type offloat would be encoded as follows:

[0268] <cost xsi:type=“float”>29.95</cost>

[0269] as contrasted with a cost parameter whose type is invariant, asfollows:

[0270] <cost>29.95</cost>

[0271] Complex Types

[0272] Beyond the simple types, SOAP defines support for the followingconstructed types:

[0273] Records/structs

[0274] Arrays

[0275] Where appropriate and possible, the representation in SOAP of avalue of a given type mirrors that used by practitioners of XML Schemas[10][11] and the common practice of the XML community at large.

[0276] Complex Values and References to Values

[0277] A complex value contains an ordered sequence of structuralmembers. When the members have distinct names, as in an instance of a Cor C++ struct, this is called a “struct,” and when the members do nothave distinct names but instead are known by their ordinal position,this is called an “array.”

[0278] The members of a complex value are encoded as accessor elements.For a struct, the accessor element name is the member name. For anarray, the accessor element name is the element type name and thesequence of the accessor elements follows the ordinal sequence of themembers.

[0279] The following is an example of a struct of type Book: <Book>  <author>Henry Ford</author>   <preface>Prefatory text</preface>  <intro>This is a book.</intro> </Book>

[0280] Below is an example of a type with both simple and compoundmembers. It shows two levels of referencing.

[0281] Note that the “href” attribute of the Author accessor element isa reference to the value whose “id” attribute matches; a similarconstruction appears for the Address. <Book>   <title>My Life andWork</title>   <author href=“#Person-1”/> </Book> <Person id=“Person-1”>  <name>Henry Ford</name>   <address href=“#Address-2”/> </Person><Address id=“Address-2”>    <email>henryford@hotmail.com</email>  <web>www.henryford.com</web> </Address>

[0282] The form above is appropriate when the Person value and theAddress value are multi-reference. If these were instead bothsingle-reference, they SHOULD be embedded, as follows: <Book>  <title>My Life and Work</title>   <author>     <name>Henry Ford</name>    <address>       <email>henryford@hotmail.com</email>      <web>www.henryford.com</web>     </address>   </author> </Book>

[0283] If instead there existed a restriction that no two persons canhave the same address in a given instance and that an address can beeither a Street-address or an Electronic-address, a Book with twoauthors would be encoded as follows: <Book>   <title>My Life andWork</title>   <firstauthor href=“#Person-1”/>   <secondauthorhref=“#Person-2”/> </Book> <Person id=“Person-1”>   <name>HenryFord</name>   <address xsi:type=“m:Electronic-address”>    <email>henryford@hotmail.com</email>    <web>www.henryford.com</web>   </address> </Person> <Personid=“Person-2”>   <name>Samuel Crowther</name>   <addressxsi:type=“n:Street-address”>     <Street>Martin Luther King Rd</Street>    <City>Raleigh</City>     <State>North Carolina</State>   </address></Person>

[0284] Generic Records

[0285] There are cases where a struct is represented with its membersnamed and values typed at run time. Even in these cases, the existingrules apply. Each member is encoded as an element with matching name,and each value is either contained or referenced. Contained values MUSThave an “xsi:type” attribute giving the type of the value.

[0286] Arrays

[0287] The representation of the value of an array is an orderedsequence of elements constituting items of the array. The element namefor each element is the element type.

[0288] As with complex types generally, if the type of an item in thearray is a single-reference type, each item contains its value.Otherwise, the item references its value via an href attribute.

[0289] The following example is an array containing integer arraymembers. The length attribute is optional. <SOAP-ENC:ArraySOAP-ENC:arrayType=“u:int[2]”>   <item>3</item>   <item>4</item></SOAP-ENC:Array>

[0290] The following is an example of a two-dimensional array ofstrings. <SOAP-ENC:Array SOAP-ENC:arrayType=“u:string[2,3]”>  <string>r1c1</string>   <string>r1c2</string>   <string>r1c3</string>  <string>r2c1</string>   <string>r2c2</string>   <string>r2c3</string></SOAP-ENC:Array>

[0291] The following is an example of an array of two arrays, each ofwhich is an array of strings. <SOAP-ENC:ArraySOAP-ENC:arrayType=“SOAP-ENC:Array[2]”>   <SOAP-ENC:Arrayhref=“#array-1”/>   <SOAP-ENC:Array href=“#array-2”/> </SOAP-ENC:Array><SOAP-ENC:Array id=“array-1” SOAP- ENC:arrayType=“u:string[3]”>  <string>r1c1</string>   <string>r1c2</string>   <string>r1c3</string></SOAP-ENC:Array> <SOAP-ENC:Array id=“array-2” SOAP-ENC:arrayType=“u:string[2]”>   <string>r2c1</string>  <string>r2c2</string> </SOAP-ENC:Array>

[0292] Finally, the following is an example of an array of phone numbersembedded in a struct of type Person and accessed through the accessor“phone-numbers”: <Person> <name>John Hancock</name>   <phone-numbersSOAP-ENC:arrayType=“u:string[2]”>     <string>111-2222</string>    <string>999-0000</string>   </phone-numbers> </Person>

[0293] A multi-reference array is always encoded as an independentelement whose element name is “SOAP-ENC:Array”. For example an array oforder structs encoded as an independent element: <SOAP-ENC:ArraySOAP-ENC:arrayType=“u:Order[2]”>   <Order>      <Product>Apple</Product>    <Price>1.56</Price>   </Order>   <Order>    <Product>Peach</Product>     <Price>1.48</Price>   </Order></SOAP-ENC:Array>

[0294] A single-reference array is encoded as an embedded element whoseelement name is the accessor name. <PurchaseOrder>   <CustomerName>HenryFord</CustomerName>   <ShipTo>     <Street>5th Ave</Street>    <City>New York</City>     <State >NY</State>     <Zip>10010</Zip>  </ShipTo>   <PurchaseLineItems SOAP-ENC:arrayType=”u:Order[2]”>    <Order>       <Product>Apple</Product>       <Price>1.56</Price>     </Order>     <Order>       <Product>Peach</Product>      <Price>1.48</Price>     </Order>   </PurchaseLineItems></PurchaseOrder>

[0295] Note that it is explicitly legal per this specification to followthe style used for serializing arrays and yet not explicitly mark anelement as being an array. See the PurchaseLineItems element in theexample here: <PurchaseOrder>   <CustomerName>Henry Ford</CustomerName>  <ShipTo>     <Street>5th Ave</Street>     <City>New York</City>    <State>NY</State>     <Zip>10010</Zip>   </ShipTo>  <PurchaseLineItems>     <Order>       <Product>Apple</Product>      <Price>1.56</Price>     </Order>     <Order>      <Product>Peach</Product>       <Price>1.48</Price>     </Order>  </PurchaseLineItems> </PurchaseOrder>

[0296] Partially Transmitted Arrays

[0297] SOAP provides support for partially transmitted arrays, known as“varying” arrays, in some contexts [12]. A partially transmitted arrayindicates in an “offset” attribute the zero-origin index of the firstelement transmitted; if omitted, the offset is taken as zero.

[0298] The following is an example of an array of size five thattransmits only the third and fourth element: <SOAP-ENC:ArraySOAP-ENC:arrayType=“u:string[5]” offset=“[2]”>   <string>The thirdelement</string>   <string>The fourth element</string> </Arrayofstring>

[0299] Sparse Arrays

[0300] SOAP provides support for sparse arrays in some contexts. Eachelement contains a “position” attribute that indicates its positionwithin the array. The following is an example of array of arrays ofstrings: <SOAP-ENC:Array SOAP-ENC:arrayType=“u:string[,] [2]”>  <Arrayofstring href=“#array-1” position=“[2]”/> </SOAP-ENC:Array><SOAP-ENC:Array id=“array-1” SOAP- ENC:arrayType=“u:string[10,10]”>  <string position=“[2,2] ”>The third element”</item>   <stringposition=“[7,2] ”>The eighth element</item> </SOAP-ENC:Array>

[0301] Assuming that the only reference to array-1 occurs in theenclosing array, this example could also have been encoded as follows:<SOAP-ENC:Array xsi:type=“string[,] [2]”>   <SOAP-ENC:Arrayposition=“[2]”>     <SOAP-ENC:Array xsi:type=“string[10,10]”>      <string position=“ [2,2] ”>The third element“</string>      <string position=“ [7,2] ”>The eighth element</string>    </SOAP-ENC:Array>   </SOAP-ENC:Array> </SOAP-ENC:Array>

[0302] Default Values

[0303] An omitted accessor element implies either a default value orthat no value is known. The specifics depend on the accessor, method,and its context. Typically, an omitted accessor implies a Null value forpolymorphic accessors (with the exact meaning of Nullaccessor-dependent). Typically, an omitted Boolean accessor implieseither a False value or that no value is known, and an omitted numericaccessor implies either that the value is zero or that no value isknown.

[0304] SOAP Root Attribute

[0305] The SOAP root attribute can be used to label serialization rootsthat are not true roots of an object graph so that the object graph canbe deserialized. The attribute can have one of two values, either “1” or“0”. True roots of an object graph have the implied attribute value of“1”. Serialization roots that are not true roots can be labeled asserialization roots with an attribute value of “1” An element canexplicitly be labeled as not being a serialization root with a value of“0”.

[0306] The SOAP root attribute MAY appear on any subelement within theSOAP Header and SOAP Body elements. The attribute does not have adefault value.

[0307] Using SOAP in HTTP

[0308] This section describes how to use SOAP within HTTP with orwithout using the HTTP Extension Framework. Binding SOAP to HTTPprovides the advantage of being able to use the formalism anddecentralized flexibility of SOAP with the rich feature set of HTTP.Carrying SOAP in HTTP does not mean that SOAP overrides existingsemantics of HTTP but rather that the semantics of SOAP over HTTP mapsnaturally to HTTP semantics.

[0309] SOAP naturally follows the HTTP request/response message modelproviding SOAP request parameters in a HTTP request and SOAP responseparameters in a HTTP response. Note, however, that SOAP intermediariesare NOT the same as HTTP intermediaries. That is, an HTTP intermediaryaddressed with the HTTP Connection header field cannot be expected toinspect or process the SOAP entity body carried in the HTTP request.

[0310] HTTP applications MUST use the media type “text/xml” whenincluding SOAP entity bodies in HTTP messages.

[0311] SOAP HTTP Request

[0312] Although SOAP might be used in combination with a variety of HTTPrequest methods, this binding only defines SOAP within HTTP POSTrequests.

[0313] The SOAPAction HTTP Header Field

[0314] The SOAPAction HTTP request header field can be used to indicatethe intent of the SOAP HTTP request. The value is a URI identifying theintent. SOAP places no restrictions on the format or specificity of theURI or that it is resolvable. An HTTP client MUST use this header fieldwhen issuing a SOAP HTTP Request.  soapaction  = “SOAPAction” “:” [ <“>URI-reference <”> ] URI-reference = <as defined in RFC 2396 [4]>

[0315] The presence and content of the SOAPAction header field can beused by servers such as firewalls to appropriately filter SOAP requestmessages in HTTP. The header field value of empty string (“”) means thatthe intent of the SOAP message is provided by the HTTP Request-URI. Novalue means that there is no indication of the intent of the message.

[0316] Examples: SOAPAction: “http://electrocommerce.org/abc#MyMessage”SOAPAction: “myapp.sdl” SOAPAction: “ ” SOAPAction:

[0317] SOAP HTTP Response

[0318] SOAP HTTP follows the semantics of the HTTP Status codes forcommunicating status information in HTTP. For example, a 2xx status codeindicates that the client's request including the SOAP component wassuccessfully received, understood, and accepted etc.

[0319] In case of a SOAP error while processing the request, the SOAPHTTP server MUST issue an HTTP 500 “Internal Server Error” response andinclude a SOAP message in the response containing a SOAP Fault elementindicating the SOAP processing error.

[0320] The HTTP Extension Framework

[0321] A SOAP message MAY be used together with the HTTP ExtensionFramework [6] in order to identify the presence and intent of a SOAPHTTP request.

[0322] Whether to use the Extension Framework or plain HTTP is aquestion of policy and capability of the communicating parties. Clientscan force the use of the HTTP Extension Framework by using a mandatoryextension declaration and the “M-” HTTP method name prefix. Servers canforce the use of the HTTP Extension Framework by using the 510 “NotExtended” HTTP status code. That is, using one extra round trip, eitherparty can detect the policy of the other party and act accordingly.

[0323] The extension identifier used to identify SOAP using theExtension Framework is

[0324] http://schemas.xmlsoap.org/soap/envelope/

[0325] SOAP HTTP Examples

[0326] Example 3 SOAP HTTP Using POST POST /StockQuote HTTP/1.1Content-Type: text/xml Content-Length: nnnn SOAPAction:“http://electrocommerce.org/abc#MyMessage” <SOAP-ENV:Envelope HTTP/1.1200 OK Content-Type: text/xml Content-Length: nnnn <SOAP-ENV:Envelope

[0327] Example 4 SOAP Using HTTP Extension Framework M-POST /StockQuoteHTTP/1.1 Man: “http://schemas.xmlsoap.org/soap/envelope/”; ns=NNNNContent-Type: text/xml Content-Length: nnnn NNNN-SOAPAction:“http://electrocommerce.org/abc#MyMessage” <SOAP-ENV:Envelope HTTP/1.1200 OK Ext: Content-Type: text/xml Content-Length: nnnn<SOAP-ENV:Envelope

[0328] Using SOAP for RPC

[0329] One of the design goals of SOAP is to encapsulate and exchangeRPC calls using the extensibility and flexibility of XML. In order toprovide a uniform mechanism for representing a method call and response,SOAP defines a mapping to be used with the SOAP encoding. This mappingis implied whenever the SOAP encoding is used.

[0330] Using SOAP for RPC is orthogonal to the SOAP protocol binding. Inthe case of using HTTP as the protocol binding, an RPC call mapsnaturally to an HTTP request and an RPC response maps to an HTTPresponse. However, using SOAP for RPC is not limited to the HTTPprotocol binding.

[0331] To make a method call, the following information is needed:

[0332] The URI of the target object

[0333] A method name

[0334] An optional method signature

[0335] The parameters to the method

[0336] Optional header data

[0337] SOAP relies on the protocol binding to provide a mechanism forcarrying the URI. For example, for HTTP the request URI indicates theresource that the invocation is being made against. Other than it be avalid URI, SOAP places no restriction on the form of an address (see [4]for more information on URIs).

[0338] RPC and SOAP Body

[0339] RPC method calls and responses are both carried in the SOAP Bodyelement using the following encoding

[0340] The method name is the first immediate child element of the SOAPBody element

[0341] Method parameters ([in] and [in/out] for a request, [in/out] and[out] for a response) are each encoded as child elements of the methodname element using the following rules:

[0342] The name of the parameter in the method signature is used as thename of the corresponding element.

[0343] Parameter values are expressed using the above rules.

[0344] RPC faults are expressed using the SOAP Fault element.

[0345] Processing of requests in the face of missing parameters isapplication defined.

[0346] Because a result indicates success and a fault indicates failure,it is an error for the method response to contain both a result and afault.

[0347] RPC and SOAP Header

[0348] An example of the use of the header element is the passing of atransaction ID along with a message. Since the transaction ID is notpart of the signature and is typically held in an infrastructurecomponent rather than application code, there is no direct way to passthe necessary information with the call. By adding an entry to theheaders and giving it a fixed name, the transaction manager on thereceiving side can extract the transaction ID and use it withoutaffecting the coding of remote procedure calls.

[0349] References for this Appendix

[0350] [1] S. Bradner, “The Internet Standards Process—Revision 3”,RFC2026, Harvard University, October 1996

[0351] [2] S. Bradner, “Key words for use in RFCs to IndicateRequirement Levels”, RFC 2119, Harvard University, March 1997

[0352] [3] D. Crocker, P. Overell, “Augmented BNF for SyntaxSpecifications: ABNF”, RFC 2234, Internet Mail Consortium, DemonInternet Ltd. November 1997

[0353] [4] T. Berners-Lee, R. Fielding, L. Masinter, “Uniform ResourceIdentifiers (URI): Generic Syntax”, RFC 2396, MIT/LCS, U.C. Irvine,Xerox Corporation, August 1998.

[0354] [5] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T.Berners-Lee, “Hypertext Transfer Protocol—HTTP/1.1”, RFC 2616, U. C.Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997

[0355] [6] H. Nielsen, P. Leach, S. Lawrence, “An HTTP ExtensionFramework”, RFC 2774, Microsoft, Microsoft, Agranat Systems

[0356] [7] W3C Recommendation “The XML Specification”

[0357] [8] W3C Recommendation “Namespaces in XML”

[0358] [9] W3C Working Draft “XML Linking Language”. This is work inprogress.

[0359] [10] W3C Working Draft “XML Schema Part 1: Structures”. This iswork in progress.

[0360] [11] W3C Working Draft “XML Schema Part 2: Datatypes”. This iswork in progress.

[0361] [12] Transfer Syntax NDR, in “DCE 1.1: Remote Procedure Call”

[0362] [13] N. Freed, N. Borenstein, “Multipurpose Internet MailExtensions (MIME) Part One: Format of Internet Message Bodies”, RFC2045,Innosoft, First Virtual, November 1996

[0363] SOAP Envelope Examples

[0364] Sample Encoding of Call Requests

[0365] Example 5 Similar to Example 1 but with a Mandatory Header POST/StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type:text/xml Content-Length: nnnn SOAPAction: “Some-URI” <SOAP-ENV:Envelope xmlns:SOAP- ENV=“http://schemas.xmlsoap.org/soap/envelope/”  SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/>  <SOAP-ENV:Header>     <t:Transaction       xmlns:t=“some-URI”      SOAP-ENV:mustUnderstand=“1”>         5     </t:Transaction>  </SOAP-ENV:Header>   <SOAP-ENV:Body>     <m:GetLastTradePricexmlns:m=“Some-URI”>       <symbol>DEF</symbol>    </m:GetLastTradePrice>   </SOAP-ENV:Body> </SOAP-ENV:Envelope>

[0366] Example 6 Similar to Example 1 but with a Struct POST /StockQuoteHTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xmlContent-Length: nnnn SOAPAction: “Some-URI” <SOAP-ENV:Envelope xmlns:SOAP- ENV=“http://schemas.xmlsoap.org/soap/envelope/”  SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/>  <SOAP-ENV:Body>     <m:GetLastTradePriceDetailed     xmlns:m=“Some-URI”>        <Symbol>DEF</Symbol>       <Company>DEFCorp</Company>       <Price>34.1</Price>    </m:GetLastTradePriceDetailed>   </SOAP-ENV:Body></SOAP-ENV:Envelope>

[0367] Sample Encoding of Response

[0368] Example 7 Similar to Example 2 but with a Mandatory HeaderHTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn<SOAP-ENV:Envelope  xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”  SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/>  <SOAP-ENV:Header>     <t:Transaction>      xmlns:t=“some-URI”     xsi:type=“int” mustUnderstand=“1”>       5     </t:Transaction>  </SOAP-ENV:Header>   <SOAP-ENV:Body>     <m:GetLastTradePriceResponse     xmlns:m=“Some-URI”>       <Price>34.5</Price>    </m:GetLastTradePriceResponse>   </SOAP-ENV:Body></SOAP-ENV:Envelope>

[0369] Example 8 Similar to Example 2 but with a Struct HTTP/1.1 200 OKContent-Type: text/xml Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP- ENV=“http://schemas.xmlsoap.org/soap/envelope/”  SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/>  <SOAP-ENV:Body>     <m:GetLastTradePriceResponse     xmlns:m=“Some-URI”>       <PriceAndVolume>         <LastTradePrice>            34.5         </LastTradePrice>         <DayVolume>            10000         </DayVolume>       </PriceAndVolume>    </m:GetLastTradePriceResponse>   </SOAP-ENV:Body></SOAP-ENV:Envelope>

[0370] Example 9 Similar to Example 2 but Failing to Honor MandatoryHeader HTTP/1.1 500 Internal Server Error Content-Type: text/xmlContent-Length: nnnn <SOAP-ENV:Envelope  xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”>   <SOAP-ENV:Body>    <SOAP-ENV:Fault>       <faultcode>MustUnderstand</faultcode>      <faultstring>SOAP Must Understand Error</faultstring>    </SOAP-ENV:Fault>   </SOAP-ENV:Body> </SOAP-ENV:Envelope>

[0371] Example 10 Similar to Example 2 but Failing to Handle BodyHTTP/1.1 500 Internal Server Error Content-Type: text/xmlContent-Length: nnnn <SOAP-ENV:Envelope  xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”>   <SOAP-ENV:Body>    <SOAP-ENV:Fault>       <faultcode>Server</faultcode>      <faultstring>Server Error</faultstring>       <detail>        <e:myfaultdetails xmlns:e=“Some-URI”>           <message>           My application didn't work           </message>          <errorcode>            1001           </errorcode>        </e:myfaultdetails>       </detail>     </SOAP-ENV:Fault>  </SOAP-ENV:Body> </SOAP-ENV:Envelope>

1. A deserialization method comprising: parsing a message; the messagecomprising a serialized object comprising: a data structure(“datastruct”) element representative of a data structure of a firstobject, the datastruct element having a pair of datastruct tags, whereinthe datastruct tags identify the datastruct element; contents of thedatastruct between the datastruct tags, the contents comprising one ormore data parameter elements representative of one or more dataparameters of the object's data structure, each parameter element havinga pair of parameter tags associated therewith, wherein each pair ofparameter tags identifies a parameter element with which the pair oftags is associated, each parameter element having associated databetween the parameter tags.
 2. A method as recited in claim 1 furthercomprising receiving the message comprising a serialized object.
 3. Amethod as recited in claim 1, further comprising: generating a secondobject having the same data structure as the first object, wherein thedata structure of the second object is based upon the datastruct elementand its contents; inserting data associated with each parameter elementinto the second object.
 4. A method as recited in claim 1, wherein thecontents further comprise at least one object reference referencing asecond object within the data structure of the first object withoutincluding the second object within the contents of the datastructelement.
 5. A method as recited in claim 1, wherein the second object isthe first object.
 6. A method as recited in claim 1, wherein thecontents comprises a datatype definition for at least one data parameterelement.
 7. A method as recited in claim 1, wherein the contentscomprises a reference to a datatype definition for at least one dataparameter element.
 8. A method as recited in claim 1, wherein at leastone of the pair of datastruct tags comprises a datatype definition forat least one data parameter element.
 9. A method as recited in claim 1,wherein at least one of the pair of datastruct tags comprises areference to a datatype definition for at least one data parameterelement.
 10. A method as recited in claim 1, wherein the datastructelement and its contents are encoded using XML.
 11. A method as recitedin claim 1, wherein a data parameter element has the following format:<parameter_label> parameter_data </parameter_label> the<parameter_label> being one of the pair of parameter tags, the</parameter_label> being the other of the pair of parameter tags, andthe parameter_label identifying the data parameter element; theparameter_data being the data associated with the parameter elementidentified by the parameter_label.
 12. A computer-readable storagemedium having computer-executable instructions that, when executed by acomputer, performs the method as recited in claim
 1. 13. Adeserialization method comprising: parsing a message; the messagecomprising a serialized object comprising: a data structure(“datastruct”) element having a pair of datastruct tags encoded in XML,wherein the datastruct tags identify the datastruct; contents of thedatastruct between the datastruct tags, the contents comprising one ormore data parameter elements, each having a pair of parameter tagsassociated therewith and encoded in XML, wherein each pair of parametertags identifies a parameter element with which the pair of tags isassociated, each parameter element having associated data between theparameter tags
 14. A computer-readable storage medium havingcomputer-executable instructions that, when executed by a computer,performs a method of parsing a message received from an entity on anetwork, the method comprising: parsing a message; the messagecomprising a serialized object comprising: a data structure(“datastruct”) element representative of a data structure of a firstobject, the datastruct element having a pair of datastruct tags, whereinthe datastruct tags identify the datastruct element; contents of thedatastruct between the datastruct tags, the contents comprising one ormore data parameter elements representative of one or more dataparameters of the object's data structure, each parameter element havinga pair of parameter tags associated therewith, wherein each pair ofparameter tags identifies a parameter element with which the pair oftags is associated, each parameter element having associated databetween the parameter tags.
 15. An apparatus comprising: a processor; amessage transmitter executable on the processor to: transmit a messageto an entity over a network; the message comprising a serialized objectcomprising: a data structure (“datastruct”) element representative of adata structure of an object, the datastruct element having a pair ofdatastruct tags, wherein the datastruct tags identify the datastructelement; contents of the datastruct between the datastruct tags, thecontents comprising one or more data parameter elements representativeof one or more data parameters of the object's data structure, eachparameter element having a pair of parameter tags associated therewith,wherein each pair of parameter tags identifies a parameter element withwhich the pair of tags is associated, each parameter element havingassociated data between the parameter tags.
 16. An apparatus comprising:a processor; a message parser executable on the processor to: parse amessage; the message comprising a serialized object comprising: a datastructure (“datastruct”) element representative of a data structure of afirst object, the datastruct element having a pair of datastruct tags,wherein the datastruct tags identify the datastruct element; contents ofthe datastruct between the datastruct tags, the contents comprising oneor more data parameter elements representative of one or more dataparameters of the object's data structure, each parameter element havinga pair of parameter tags associated therewith, wherein each pair ofparameter tags identifies a parameter element with which the pair oftags is associated, each parameter element having associated databetween the parameter tags.